Lev G.

Santa писал(а) Thu, 13 December 2012 09:40Mih-mih писал(а) Thu, 13 December 2012 09:29Треки на гпсиес теряют половину от своей полезности.Реальное время да, "уходит". Но там зато импорт-экспорт треков без заморочек с кучей поддерживаемых форматов. Предложите вариант лучше. Например, на gpslib.ru реальное время после скачивания трека сохраняется! Но я полагаю, несмотря на это сервис gpsies.com именно для нужд ВелоПути по совокупности факторов: из за своей обзорности, возможности сразу вставить ссылку на отчет в трек, хорошей системы поиска трека.. будет все же предпочтительнее других вариантов.

Отчет добавлен в список отчетов. terra Друзья ВелоПитерцы предлагаю совершить велопоход по русскому Заполярью, насладиться красотой северной природы, увидеть берег Ледовитого океана... Сроки похода 7-17 августа 2012г Сроки с учетом заброски 6-19 августа 2012г Цель похода чисто познавательная - увидеть максимум красивых мест, "зарабатывать" какие либо категории сложности не планируется. Туда забрасываемся на 22 поезде (СПб-Мурманск) 6 августа в 17:20 с Ладожского вкз. , едем до Апатит, откуда 7 августа в 16:47 начинаем наш поход. Предварительный маршрут: 7 авг. Апатиты - Кировск - оз. Мал Вудъявр 25км 8 авг. оз. Мал Вудъявр - пер. Кукисвумчорр - вдп Рисчорр - пер. Юж. Рисчорр - оз. Академическое 30км 9 авг. оз.Академическое - Умбозеро (м. Литт) 50км 10 авг. Умбозеро - пер.Геологов - р.Чинглусуай - Сейдозеро 60км 11 авг. Сейдозеро - Ревда 30км 12-13авг Ревда - Мурманск 150км 14авг Мурманск Дневка. Катаем по лучшим местам города или отдыхаем. Ночевки в городских условиях у друга. (или Резервный день) 15 авг Мурманск - Териберка 140км 16 авг Баренцево море Дневка 17 авг Териберка -Мурманск 140км 18 авг Едем домой на поезде 21 Мурманск - СПб в 09:12 В Питере 19авг в 12:11 Итого около 660км за 11 дней (60км/день) Это не много по километрам, НО определенная сложность похода по Хибинам в том, что дорог там мало и потребуется проходить множество ручьев и бродов и будут подъемы/спуски по каменистым тропам. Необходимо быть готовым к этому технически (запасная обувь, одежда, желательны покрышки с протектором) и морально. Маршрут не догма, если у кого есть советы, пожелания по маршруту буду рад выслушать и возможно внести коррективы. Пока участников двое: я и мой друг Дима(Мурманск) Имеется палатка трешка(есть место), котелки разные, горелка газовая

Слава-байкер знаменитый писал(а) Mon, 10 December 2012 18:40 От себя добавлю, что езжу с частыми остановками и разгонами - вероятно и эту свою лепту вносит в медленное перемещение на твентинайнере, разгоняется который чрезвычайно тяжело. Из таких мелочей и складывается мизерный дневной пробег на большеколёснике. Именно так, только при больших пробегах это уже совсем не мелочи. Многие, никогда в жизни не ездившие много км за день, наверное сейчас читают и не понимают вас, зачем же ездить с постоянными разгонами, но я то это хорошо понимаю. Вы очевидно использую методику езды накатом( крутнул 3-4 раза педаль и едешь накатом, потом через некоторое время опять..) Теоретически это может наверное объяснить биомеханика. Смысл в том, что при постоянных нагрузках мышцы человека рано или поздно "забиваются" и требует все больший интервал для восстановления их работоспособности. В таких условиях педалировать непрерывно становиться невозможно. Пожалуй единственный и правильный способ преодолеть большие расстояния на велосипеде это использовать методику наката! На своем опыте я убедился в эффективности этого, когда мне необходимо было проехать >200км в день. Но для этого должно быть выполнено по крайне мере два важных условия. Во первых силы трения во втулке должны быть минимальными, т. е. колесо должно долго крутиться после прекращения педалирования(зависит от качества втулки или степени затянутости конусов). Во вторых размер колеса не должен быть большим. Очевидно, что использование методики езды накатом в условиях когда сил на непрерывный педалеж уже не остается, в случае с найнером не даст практически никакого эффекта, т. к. раскрутить найнерские колеса гораздо сложнее. Пока мы не устали и едем первые 10-20км педалируя непрерывно мы будем наслаждаться преимуществами 29' колеса. Но по мере накопления усталости в мышцах эти преимущества быстро тают превращаясь в недостатки. По большому счету разумнее даже не дожидаться сильной усталости мышц, а периодически применять методику езды накатом, чтобы отсрочить момент наступления критической усталости, это позволит сэкономить больше сил и увеличит ваш дневной пробег( в тех случаях если вам нужно проехать >100 км)

Андрей Сахаров писал(а) Mon, 10 December 2012 22:25Для оптимальной катимости вела по асфальту диаметр колеса должен быть равен росту, делённому на 2,6. Учитывая, что 1 дюйм равен 2.54см и произведя несложные математические расчеты получаем оптимальный размер колес в зависимости от роста человека: < 165 см - 24' 165 - 178 см - 26' 178 -188 см - 28' > 188 см - 29' А теперь вопрос сколько процентов людей имеет рост выше 178см? А выше 188см? А теперь самое интересное, если выбор делать только между 26 и 29, то получаем такие оптимальные значения: < 181.6 см - 26' > 181.6 см - 29'

TarasB писал(а) Mon, 10 December 2012 21:35 но если человек выбрал оптимальную длину, то нахрен ему не впёрлось ставить более длинные шатуны чтобы лезть в гору - мощность будет меньше. Ну можно типа предположить, что более длинные шатуны уменьшают долговременную мощность, повышая кратковременную, но это уже хрень по-моему. Вот именно хрень, ЗАЧЕМ если он выбрал ОПТИМАЛЬНУЮ длинну шатунов , ОПТИМАЛЬНУЮ высоту седла зачем ему выше или ниже, ОПТИМАЛЬНУЮ количество скоростей зачем ему больше или меньше, длину руля, размер рамы и т. д. и т. п., то почему же он должен выбрать НЕ ОПТИМАЛЬНЫЙ размер колеса??? Где логика? Ну хоть кто-то понял смысл моего поста. Если 26' в большинстве случаев оптимален для велотуризма, зачем нам следовать очередным уловкам маркетологов (и переходить на 29' колеса) всегда ищущих не без успеха все новые способы нам что-то продать, в ущерб своему увлечению?

Михалыч Уфимский писал(а) Mon, 10 December 2012 20:51продам найнер обменяю на вел с 24" колесами и всех обгоню... В велосипеде все должно быть оптимизировано для данного конкретного человека и для данных задач. Вот примеры: 1) Слишком низко опущенное седло - быстрое наступление усталости при езде, слишко высоко поднятое - риск получить растяжение. 2) Слишком длинные шатуны легче вкрутить в гору, но быстрее наступает усталость и могут быть боли в коленях. Слишком короткие шатуны быстрее едешь, но сложнее вкрутить в гору. 3) Слишком много передач везде проедешь, но больше вес чуть меньше скорость. Слишком мало передач - быстрее поедешь, но пойдешь в гору пешком или "убьешь" колени вкручивая. ... Наш выбор зачастую это разумный компромис между чем то. Важно не ударяться в крайности в погоне за одними преимуществами и утратить другие более важные для нас. Для людей с очень маленьким ростом разумнее будет 24'(тут проблема может быть только с поиском качественных комплектующих), а для детей и 20' Это логично. Вы наверное не посадите ребенка на 29' только потому, что многие гонцы теперь на таких катают? По теме был пример с велосипедом для туризма со всеми вытекающими. Т. е. задачи какие должны стоять, минимизировать усталость при езде на дальние расстояния, максимизировать комфорт, проходимость не в ущерб скорости(позволить себе 9кг найнер турист не может не забываем и о прочности) Именно из этого нужно исходить. Да в определенных спорт. дисциплинах найнер рулит, а в некоторых и двухподвес тоже, но это все частные случаи.

Nodens писал(а) Mon, 10 December 2012 19:13Расскажите это Hei-Hei team. Гонка на 700км за 78 часов из них 14 часов на питстопы, по горам, второе место, все на найнерах причём о ужас на подвесах. http://velopiter.spb.ru/forum/index.php?t=msg&th=152243&goto=1090572&rid=2287#msg_1090572 С интересом читал этот пост. Скажите, а какой тип велосипеда был у лидеров этой гонки? Уж не хардтейл ли на 26' Кто знает, возможно что этот выбор найнеров двухподвесов как раз и отдалил наших ребят от первого места в этой гонке. Опять же какой их рост, длинна ног? Может найнер им действительно больше подходил, а двухподвес был выбран из-за супер длинной дистанции из-за оправданной боязни, что 5 точка могла не дотерпеть до финиша.

blk_104 писал(а) Mon, 10 December 2012 18:40Lev G. писал(а) Mon, 10 December 2012 15:31А чем больше диаметр колеса (или длинна шатуна) тем раньше наступает у человека усталость. Такова физиология человека. Какова "такова"? Человек не крутит колёса, он крутит педали на шатунах. Если на больший диаметр колеса поставить настолько же меньшую передачу, передаточный коэффициент (а с ним требуемое усилие, и, значит, наступление усталости) останется прежним. Разница может быть только, если от диаметра колеса зависит сопротивление качению. Это не так. Во первых вес вращающейся массы у 29' больше, а следовательно больше энергии для ее раскрутки (а вклад веса колеса в энергозатраты как известно примерно на порядок важнее веса остальных частей велосипеда), во вторых сопротивление встречного воздушного потока из за больших габаритов 29' больше. Не говоря уже о худшей маневренности и устойчивости 29' что особо актуально на опасных горных спусках, учитывая груз на багажнике. Limon4ik писал(а) Mon, 10 December 2012 18:43Lev G. писал(а) Mon, 10 December 2012 18:31 ..Рад, что наконец нашелся хоть один человек, который осмелился спустить большинство найнероводов с небес на землю и открыть им горькую правду.. Бедные, бедные найнероводы! Только сейчас узнали правду. А свой опыт и показания спидометра они должны сразу забраковать и поверить другому дяде. Беда. Верить никому и никогда нельзя. Тем более в наше то время. Лишь практика есть критерий истины. Попробуйте поехать в серьезный поход (с разнообразным покрытием, рельефом, набором высоты, длительным дневным километражем) на 26' и сравните свои ощущения с 29'. Вы поймете, что даже на асфальте у 29' не будет серьезных преимуществ, тем более когда сзади рюкзак, а впереди подъем

blk_104 писал(а) Mon, 10 December 2012 17:25Ну а объяснение этому есть какое-то? То есть понятно, что колеса с большей массой на окружности труднее раскрутить, но это должно касаться исключительно разгона (и торможения -- нужно большее тормозное усилие), а поддерживать скорость теоретически должно быть никак не труднее, чем на меньших колёсах. Теория эта работает только на коротких дистанциях. Если речь о походах с суточными пробегами >100км то тут главное что, выносливость! А чем больше диаметр колеса (или длинна шатуна) тем раньше наступает у человека усталость. Такова физиология человека. Если бы все было так просто, чем больше диаметр колеса тем больше ты проедешь, то маркетологи не остановились бы и давно уже стали продвигать велики и на 31 и на 33 ... дюймовых колесах Для большинства людей (со средним и маленьким ростом) на самом деле именно 26 дюймов идеальный размер колеса. На таком велосипеде они смогут проехать большие расстояния с меньшими затратами сил. И лишь для высоких (длинноногих) людей можно рекомендовать 29 дюймовые колеса и длинные шатуны. Рад, что наконец нашелся хоть один человек, который осмелился спустить большинство найнероводов с небес на землю и открыть им горькую правду Для меня же преимущества 26 дюймовых велосипедов никогда не вызывали сомнения, достаточно было попробовать немного прокатиться на разных 29 дюймовых велах друзей.

VPom писал(а) Tue, 04 December 2012 12:41Lev G. писал(а) Tue, 04 December 2012 14:37 Постараюсь выразиться точнее. Потеря сигнала всегда вызывает завершение секции в треке! В вашем конкретном случае - да. В общем случае - нет. Так что ваша программа годится для обработки ваших треков. Но не других. Вполне допускаю, что имеющийся в моей программе так называемый "метод поиска слабого сигнала" для некоторых особенных треков не даст никаких результатов за неимением секций в этих треках. Но другие 2 предложенных мной метода будут работать даже сейчас. А если еще усовершенствовать довольно сырой алгоритм метода "отрезков": ввести обработку азимутов, поэкспериментировать с длинной отрезков... я уверен что треки ваших заказчиков могут быть обработаны еще более качественно и корректно. Я не обещаю 100% гарантии поиска всех вылетевших точек(тут имеем дело с вероятностями) особенно когда 20% точек трека скачут на 1км как в вашем примере, но максимально увеличит вероятность нахождения таких точек задача которая должна быть нам по силам. Что касается вашего предложения возвращать вылетевшие точки "туда где они должны быть", считаю это неправильным подходом, и вот почему. В данные трека не попадает информации о точности определения координат для каждой конкретной точки трека. Без таких данных мы не можем аппроксимировать данную точку иначе как поставив ее тупо посередине между двумя соседними точками, признанными верными. Но в этом же нет никакого смысла. Или, быть может, ваши заказчики требуют чтобы трек после обработки содержал такое же количество точек как и до нее?

VPom писал(а) Mon, 03 December 2012 09:46 Lev G. писал(а) Fri, 30 November 2012 16:48Слабый сигнал(точнее его потерю) определяю по данным plt файла. В структуре plt файла это можно узнать по символу после 2 запятой. Если это "1" потеря сигнала, если "0" нет Вот пример: 60.363370, 29.209070,1, 175.5,41049.2970833, 20-май-12, 7:07:48 В структуре gpx файла за это отвечает такая строка </trkseg> И соответственно начало новой секции <trkseg> Могу вас заверить, что деление трека на секции никак не коррелирует с потерей сигнала. Тут возможны разные ситуации: 1. Прибор действительно начинает новую секцию при потере сигнала. 2. Прибор никак не отмечает потерю сигнала и вообще никоим образом не поддерживает секции в треке 3. Прибор закрывает текущий трек и начинает новый при потере сигнала. 4. Прибор делит трек на секции по своим внутренним соображениям. Например, по количеству точек. Или по истечении некоторого времени. Или... да бог его знает почему. Так что привязываться к сегменту трека как к точке потери сигнала некорректно. Постараюсь выразиться точнее. Потеря сигнала всегда вызывает завершение секции в треке! Но завершение секции в треке не всегда означает потерю сигнала, она может быть вызвана и выключением прибора, и началом новой даты, и изменением настроек записи трека. Т. е. начало новой секции это своего рода маркер места где очень велика вероятность появления ошибочных данных в треке. Привязываться к сегменту трека можно и нужно для удаления ошибочных данных. Более того программа OziExplorer которую писали надо полагать не совсем дураки именно это и делает при подсчете статистики, т. е. она не учитывает данные расстояния и скорости в местах начала новой секции. Если трек по каким то причинам не имеет секций(например секции были объединены в одну другой программой или сигнал не был потерян, но был так слаб, что имел огромную погрешность) как в вашем примере, то все "нереальные" скорости и расстояния попадают в статистику трека подведенную этой программой. Эту особенность я и решил использовать в алгоритме своей программы. Чтобы не только статистика не искажалась (как в Ozi), но еще и подобные точки удалялись из трека за ненадобностью. А измененный трек и выглядел бы более правдоподобно и статистика любыми другими программами (даже без такого механизма защиты как в Ozi) велась верно.

VPom писал(а) Mon, 03 December 2012 10:04 К сожалению, это вполне нормальный трек для города. VPom писал(а) Mon, 03 December 2012 09:46 Я себя отношу к счастливым необладателям сего прибора (вот уже почти полтора года как). Вот когда вы превратитесь из счастливого необладателя в обладателя прибора Garmin (на сирф-3 или мтк), видимо тогда вы перестанете считать подобные треки нормальными для города. Это не реклама Гармин, возможно что и другие производители делают нечто подобное. По крайне мере 60 серия и eTrex (не совсем древние) с такой огромной погрешностью треки в городах да и вообще где бы то ни было(за исключением разве что глубоких каньонов) не рисуют.

VPom писал(а) Thu, 29 November 2012 12:10Что-то не запускается у меня. Стоит Java 1.6.0_37 - другие аплеты запускаются без проблем, а этот ругается на то, что не может найти какой-то класс. plt - это плохо Нет у меня таких треков готовых. все в стандартном gpx (озиком не пользуюсь, давно ушел на OkMap, навигатор - Магеллан - пишет напрямую в gpx, логгер пишет в nmea, потом в gpx конвертирую). Так что проверить быстро не получилось, увы... Важно понимать, что это не апплет (программа которая помещаются на Web страницы), а приложение (самостоятельная программа выполняемая с использованием интерпретатора java). Т. е. запустить ее в окне браузера никак нельзя. Я для этого создал пусковой файл TrackAnalizator.bat Даже сам TrackAnalizator.jar может служить стартом для выполнения программы при правильно настроенных файловых ассоциациях на вашем ПК (по двойному щелчку на нем) . До недавнего момента я писал программы только для себя для использования на собственном ПК, поэтому в тонкости проблемы их переносимости на другие ПК не вдавался. В ближайшее время попробую разобраться с этим. Может быть даже имеет смысл сделать ее в виде апплета дабы гарантировать выполнение на стороннем ПО.

Вот измененный программой трек

VPom писал(а) Thu, 29 November 2012 12:29 Вот вам навскидку трек. В архиве plt в том виде, как он получен с логгера, htm - как он должен выглядеть на самом деле. Я эту задачку решить не смог пока. Да уж, это мягко говоря тяжелый случай Я бы такой трек сразу отправил в корзину. Тем не менее проанализировал его своей программой. Кое что она все таки смогла для вас сделать. Обнаружила и удалила откровенные вылеты. Вот результат ее анализа: Ваш трек Измененный трек

VPom писал(а) Thu, 29 November 2012 12:29 1. А что такое MapSource? 2. Как вы определяете "слабый сигнал"? У вас есть в треке информация и количестве видимых спутников/спутников, по которым принимается решение, или хотя бы, HDOP? 3. Почему именно "одна до и три после"? 1. MapSource - оффлайновая программа компании Garmin для работы с векторными картами. Распространяется бесплатно при покупке приборов Garmin. Соответственно есть у всех счастливых обладателей таких приборов. 2. Слабый сигнал(точнее его потерю) определяю по данным plt файла. В структуре plt файла это можно узнать по символу после 2 запятой. Если это "1" потеря сигнала, если "0" нет Вот пример: 60.363370, 29.209070,1, 175.5,41049.2970833, 20-май-12, 7:07:48 В структуре gpx файла за это отвечает такая строка </trkseg> И соответственно начало новой секции <trkseg> В случае потери сигнала первые записи после этого как правило ошибочные (проверял на множестве треков) или точки аппроксимируются в то место в котором ты уже не находишься или время сбрасывается до дефолтного 21-авг-99 Причем проанализировав много треков пришел к выводу, что иногда перед полной потерей сигнала точка уже может вылететь на 1км. В каждом треке это происходит по разному. Где-то 1 точка до этого и 3 после, где-то 0 точек до и 5 после ошибочные. Есть общая закономерность, но 100% гарантию что метод выловит "плохую" точку я конечно дать вам не могу. 3. Удалять 1 точку до и 3 после потери сигнала такое решение принято мной на основе анализа общих закономерностей своих треков, где подобные ошибки встречаются в записи трека. Конечно для треклогера или прибора с плохим приемом сигнала допускаю что другие параметры могут быть здесь более правильными. На данном этапе для меня было важно показать вам что программа эффективна и будет работать.

Santa писал(а) Thu, 29 November 2012 08:42Lev G., а как же стандартный ныне формат gpx? Тоже думал над этим. Были несколько причин по которым я решил начать писать программу сначала для plt формата, а не gpx. Во первых время, которое очень важно для расчета расстояния, а затем и скорости в plt формате находиться в абсолютных единицах с погрешностью примерно 0.01с Это довольно неплохо. В случае с gpx форматом погрешность 1с, что в 100 раз больше. Правильнее сначала проверить программу на более точных данных. Во вторых для gpx формата мне пришлось бы писать отдельный метод для перевода времени в абсолютные единицы. Уйти от формата ДД:Мес:ГГ ЧЧ:ММ:СС чтобы сравнивать время. Это отняло бы лишнее время для написания программы. В третьих я пользуюсь версией Ozi которая не поддерживает просмотр треков в ином формате кроме plt. А Ozi в отличии от других программ выдает подробную статистику по точкам, удобно сравнивать его расчеты с теми что выполнила моя программа. В четвертых любой из форматов можно легко конвертировать в другой. Например тот же gpx в plt. Проанализировать его, а затем обратно или в gpx или в популярный нынче kml(для просмотра на спутниковом снимке) кому как нравиться. Конечно программу можно дописать, чтобы она понимала и gpx формат или еще какой-то другой. Просто методы обработки строк файла будут совсем иными. Будет время возможно займусь и этим.

VPom писал(а) Sat, 17 November 2012 11:59Lev G. писал(а) Sat, 17 November 2012 01:57 Так можно ведь написать такую программу, чтоб пользователь сам задавал в программе это число. Скажем если он знает, что он более 40км/ч не ехал, выставит допустим 45 в фильтре, а если это скоростной даунхилл, то большее число. После этого программа начнет работу. Хорошо. Значит 44.99 - не выброс, а 45.01 - выброс? вы сами хоть одну такую программу написали? Думаю что нет. А я несколько лет этим вопросом в свободное время занимаюсь. Не так там все просто как кажется с первого взгляда. Чтобы стало понятнее могу предложить "домашнее задание". возьмите трек, загрузите его, скажем, в эксель, и попробуйте рассчитать какой-то критерий для каждой точки трека, по которому можно было бы однозначно сказать выброс это или нет. Не видя трек на карте, просто по координатам-времени для каждой точки. Если удастся, возьмите еще десяток-другой треков и проверьте найденный критерий на них. Уважаемый VPom будем считать, что ваши многочисленные провокации в мой адрес сработали и я решил выполнить ваше "домашнее задание": написал программу TrackAnalizator для анализа треков формата *.plt и создания нового файла трека без "ошибок". (архив с программой во вложении) Программа написана на языке Java и выполняется как приложение на ПК. Для работы приложения возможно дополнительно потребуется установить или обновить программное обеспечение java: http://www.java.com/ru/download/index.jsp По поводу реализации программы сильно не пинайте, я все ж таки не программист, а увлекаюсь этим только как хобби. Программа позволяет выявлять "плохие" точки тремя разными методами. 1) Метод слабого сигнала заключается в том, что программа находит строки в треке, где был потерян сигнал и помечает на удаление 1 точку до и 3 после этого события. Важным положительным эффектом от применения этого метода для пользователя является то, что он получает трек не разбитый на секции, а как одно целое. Просматривать его в MapSource будет гораздо приятнее 2) Метод отрезков заключается в том, что на отрезке из 4 точек сравниваются расстояние между крайними и между ближайшими точками. Если расстояние между крайними точками меньше чем между ближайшими точка помечается на удаление. К сожалению я не могу в полной мере оценить корректность его работы, т. к. треков с большими "дрифтами" нет. Конечно мой метод примитивен и тут я согласен с вами, есть огромный потенциал для творчества, можно учитывать азимуты точек, аппроксимацию... Если будет время можно попробовать вместе найти "идеальное" решение. 3) Метод "нереальных" скоростей + дополнительная опция, возможность пользователю установить самому критерий удаления точек. Это тот метод в эффективности которого я убедился уже давно. Тем кто не верит предоставляется возможность проверить его на своих треках Максимальное число точек трека для анализа в файле трека - 20 тыс шт. (не хотелось выделять черезмерно большие объемы памяти под массивы) Окно программы: Тот же файл после обработки:

Bulawka писал(а) Mon, 19 November 2012 18:48 Спасибо за хороший совет. Правда, он не настолько хорош. У меня всегда стоит "авто", при этом, например, хождение вокруг авто на открытой полянке (пока авто греется, скажем, складываем вещи, переодеваемся) пишется в виде звезды такой туда сюда. Хотя мои перемещения в пространстве существенно меньше 10 метров. "авто" - это комбинированный способ записи трека, т. е. когда скорость маленькая точки ставятся реже, а когда выше чаще. Для меня также этот способ записи наиболее привлекателен, т. к. он не дает много лишних точек при остановке(в отличии от выбора метода "время") и в то же время достаточно подробно рисует трек при больших скоростях при этом ставятся точки в важных местах поворота (в отличие от метода "расстояние"). Метод "авто" конечно 100% не защищает от "дрифтов" (ведь даже сам навигатор, за 2ч моей остановки насчитывает примерно 1км пути и 35м набора высоты ), но во всяком случае существенно уменьшит количество вылетевших точек. Близкую к 100% гарантию может дать только метод "расстояние"

VPom писал(а) Mon, 19 November 2012 09:25 Вот еще один пример. Красный трек - то, что получено с прибора. Синий - обработанный по некоторому специальному алгоритму. Здесь мы видим классический пример "дрифта". Был прокол камеры. Пока клеился, прибор был неподвижен, а записанный им трек "гулял" вокруг прибора. С такими артефактами научился бороться более-менее эффективно (не на 100%, но в большинстве случаев выявлять их умею). Не так это и просто на самом деле. Визуально-то они сразу в газа бросаются, а вот математически выделить их оказалось достаточно нетривиально. Я могу дать вам хороший совет как в принципе избежать подобных "дрифтов" на будущее. Для этого в настройках пути выберите метод записи "расстояние" или даже "авто", но только не "время". Тогда на треке точек ближе 10м (а это как раз и есть типичное максимальное значение погрешности для современных приборов) друг от друга не будет. Трек будет "гулять" при остановке только при условии очень плохого приема сигнала.

VPom писал(а) Sat, 17 November 2012 11:59Lev G. писал(а) Sat, 17 November 2012 01:57 Так можно ведь написать такую программу, чтоб пользователь сам задавал в программе это число. Скажем если он знает, что он более 40км/ч не ехал, выставит допустим 45 в фильтре, а если это скоростной даунхилл, то большее число. После этого программа начнет работу. Хорошо. Значит 44.99 - не выброс, а 45.01 - выброс? вы сами хоть одну такую программу написали? Думаю что нет. А я несколько лет этим вопросом в свободное время занимаюсь. Не так там все просто как кажется с первого взгляда. Все равно я не понимаю зачем вам понадобился четкий критерий, ради которого вы готовы потратить так много своего свободного времени? И так же очевидно, что его нет и быть не может. Само определение местоположения носит вероятностный характер. Ухудшился сигнал (почему другой вопрос) и имеем вместо +-3м уже+-15м соответственно велика вероятность что трек может улететь на 15м в сторону и никакая высшая математика вам не поможет. Тем более в ситуации когда дорога имеет изгиб, а сигнал был потерян(или сильно ухудшился) как раз перед входом в этот изгиб, как в вашем примере. VPom писал(а) Sat, 17 November 2012 11:59 Вопрос не в том, что вы думаете. Вопрос в том - где четкий однозначный критерий достоверности точки. Когда вы видите трек на карте вопросов нет. весь вопрос в том, что нужен какой-то алгоритм математической обработки трека, который однозначны выделял бы плохие точки на фоне хороших. Вы поймите, что то что предлагаю я, это не есть четкий критерий 100% отсекающий все выбросы (что по моему мнению нерешаемая задача) это лишь метод позволяющий выявить и избавиться от наиболее грубых выбросов, которые существенно могут исказить данные статистики в сторону увеличения. Например, вместо реальных 600км за велопоход(по велокомпу) по треку будет скажем 630-650км, а по набору высоты вместо 9000м будет 10000м Различия могут быть и более существенными. Я уже описал для каких случаев предлагается данный метод. Работать этот метод будет только для треков написанных современными приборами, т. е. такими, где при горячем старте потерянный сигнал ищется достаточно быстро за секунды. Тогда "улетевший" трек почти моментально возвращается на дорогу по которой вы едете и в треклог неизбежно попадают "нереальные" скорости. Выявляя их мы тем самым удаляем такие точки. Собственно я не предлагаю ничего нового, только лишь автоматизировать(путем написания программы) то, что мне и так приходилось делать вручную с некоторыми из своих треков. VPom писал(а) Sat, 17 November 2012 11:59 Что касается скорости. Ни на навигаторе, ни на велокомпе мгновенной скорости вы не видите. Тм отображается некая усредненная скорость. Тут я с вами не согласен. Если те сложные математические алгоритмы, которые вы тут описали, позволяют добиться точности определения мгновенной скорости в +-1км/ч (а это действительно так), то я имею полное право сказать, что глядя в навигатор я знаю(вижу) свою мгновенную скорость (какое для меня имеет значение как именно она там подсчитана, я же не собираюсь процессор в навигаторе разбирать ) VPom писал(а) Sat, 17 November 2012 11:59 Garmin eTrex Hа чипе Bravo2. Не менее современный, чем МТК или Сирф-3. Трек наложен на гуглеснимок в сети (программа работает через GMap API с онлайновыми картами). В одну сторону ухода нет, в другую - есть. Ни на древность чипа, ни на кривость карты тут не списать. И тут я с вами не соглашусь. Нельзя принимать спутниковые снимки Google за эталон. Я тоже раньше так думал, пока не получил пару привязок программой SASPlanet со смещением всей картинки на 50м. Когда я изготовил собственную привязку этого снимка в OZI я понял это. Несовершенны не сами спутниковые снимки, а методы их автоматической привязки в онлайновых или офф-лайновых программах. Вот и на вашем снимке видно, что весь трек смещен на юг относительно дороги. Т. е. вылет от дороги будет не 50м. а только где-то 30м. Что касается древности чипа, тут вывод смогу сделать если пришлете мне этот трек в личку с указанием времени, когда проезжали этот участок. Возможно был некий глюк, ваш прибор потерял сигнал, а пока пытался его найти аппроксимировал трек по прямой, а затем по мере повышения точности(горячий старт) трек вернулся к дороге.

VPom писал(а) Fri, 16 November 2012 10:12Lev G. писал(а) Mon, 12 November 2012 23:10 Про программу я уверен, что такую написать возможно, но для конкретных задач. Например, если транспорт велосипед то очевидно, что скорости >100км/ч из области фантастики. В программе можно сделать фильтр по скоростям зачищающий строки в файле от момента включения прибора до точек с такими скоростями если таковые будут. Увы, но это рассуждения дилетанта. Без обид, просто констатация факта. Давайте уточним. Для программы нужен четкий критерий для отбора. Иными словами - конкретное число. Больше - плохая точка ("выброс"), меньше - хорошая. Как мы определим это число? Вот вы говорите, что больше 100км/ч на велосипеде нереально. А 99 реально? Нет. Тогда сколько? 70 нереально? А 69.9? Где точная граница между реальностью и нереальностью? Так можно ведь написать такую программу, чтоб пользователь сам задавал в программе это число. Скажем если он знает, что он более 40км/ч не ехал, выставит допустим 45 в фильтре, а если это скоростной даунхилл, то большее число. После этого программа начнет работу. VPom писал(а) Fri, 16 November 2012 10:12 Но на самом деле все еще сложнее. Вот скорость 40км/ч на велосипеде реальна? Да. А когда в какой-то момент времени скорость равна нулю, через секунду она равна 40км/ч а еще через секунду опять ноль - это реально? Нет. Т.е. одной скорости, получается, недостаточно. Нужно еще и ускорение учитывать. А это еще один точный критерий - какое ускорение считать реальным, а какое нет? По поводу ускорения все гораздо проще. Ведь у 99% пользователей нет треклогеров, которые бы писали трек с интервалом <1 сек. Для треклога обычного навигатора ускорение просто невозможно вычислить поскольку точки ставятся в лучшем случае через интервал 6-10 сек(метод записи авто - совсем часто). А за такое время разогнать велосипед до 40км/ч думаю будет уже по силам, хотя не проверял Тем не менее мгновенную скорость навигатор определяет с погрешностью во всяком случае не более 1км/ч, сравнивал с велокомпьютером расхождений когда либо замечено не было! VPom писал(а) Fri, 16 November 2012 10:12 3. Есть и более сложные ситуации - массовые выбросы. Когда из трека вылетает не одна точка, а несколько. Скажем, движемся по дороге, вдруг трек скачком улетает на 100м в сторону, затем идет ровно, но со смесщением, через несколько секунд (5-10 точек) возвращается обратно. Восстанавливать такое еще сложнее чем выкинуть одну точку, заменив ее интерполяцией. А такой уход бывает и плавным - выглядит весьма натурально, как с дороги съехал в лес, проехал по лесу, потом выехал обратно на дорогу. Если не знать что с дороги не съезжал - никаких аномалий не заметишь (был где-то пример и такого трека). 4. Есть пара идей как еще можно попробовать ловить одиночные выбросы, но пока нет времени реализовать и нет уверенности, что это вообще будет работать... По поводу массовых выбросов первое что приходит в голову это кривость вашей карты, т. е. трек рисуется правильно, а дорога на карте изображена с ошибкой. Или у вас совсем древний прибор. В реальности на современных навигаторах на mtk или sirf такого никогда не наблюдал. Единственное, что бывает, так это когда в глубокий каньон или ущелье залезаешь погрешность падает с 3-4м до 10-15м и трек поэтому гулять начинает, но тут уже ничего не поделаешь. А так даже в самом густом лесу погрешность <10м и никаких выбросов ни массовых ни единичных. Для современных навигаторов, программа должна первое уметь находить начало новой секции( это и есть те моменты когда человек менял батарейки, на какое-то время выключал прибор или просто заходил в магазин с навигатором ) и анализировать первые 3-5 минут записи после этого(или то время за которое гарантированно находятся спутники и погрешность становиться <10м). Причина такого поведения навигатора в принципе мне ясна, прибор запоминает твое последнее местоположение до потери сигнала и когда ищет спутники(в первую минуту их поиска погрешность еще высока) заложенный в него сложный математический алгоритм учитывает в тот момент в большей степени твое последнее местоположение. И выдает эти координаты в треклог. Затем когда точность сигнала резко увеличивается до привычных +-3м твое прежнее местоположение уже не учитываются и в треклог попадают верные координаты (это только 3 точка в моем примере) Между точками получается большой скачек расстояния и соответственно скорости. На треклогере за это время выставиться не 3-4, а 30-40 точек и этот скачек будет плавным настолько, что его можно и не заметить. Т. е. там не будет таких "нереальных" скоростей будет только неверно начерченный трек. Отсюда вывод: написать подобную программу для типичного трека навигатора предлагаемым мной способом можно, а трека треклогера уже нельзя.

Версия велокарты обновлена на v24: 1. Достигнута полная совместимость с программой BaseCamp а также с новыми версиями MapSource! Теперь карта корректно отображается в BaseCamp, подключаются треки, работает поиск... 2. Исправлена неработающая маршрутизация до ряда жд станций 3. Нанесены некоторые дороги и проезжие тропы в разных районах Вот скриншот экрана BaseCamp. Поиск ближайших веломагазинов на карте города: Должен сказать, что на компьютере отображение ОСМ карты будет несколько красивее, но велокарта оптимизирована мной для просмотра ее через маленький экран устройства в полевых условиях (жирные четкие линии дорог, быстрая отрисовка в приборе, минимум лишних объектов), поэтому всем конечно не угодить.

Kimber1 писал(а) Mon, 12 November 2012 21:36Lev G. писал(а) Mon, 12 November 2012 21:10 Теперь по поводу точности. Если будет передаваться кривое время и будут соответственно определены кривые координаты, но зато правильная погрешность их определения это также никак не поможет в определении истинных координат Поможет. Мы же про две альтернативные системы говорим. Вес координат с большей погрешностью при вычислении средних координат будет меньше в соответствии с величиной погрешности. Вы поймите, если допустить, что будет передаваться кривое время по сигналу гпс и как следствие определяться кривые координаты по их сигналу, погрешность определения таких координат НЕ УВЕЛИЧИТЬСЯ, как было у вас допустим +- 3м так и останется (погрешность определяется только качеством приема самого сигнала со спутников!) , а значит этот заложенный в прибор алгоритм, учитывающий величину вклада разных систем в определения координат приведет к неверному определению координат.

Про программу я уверен, что такую написать возможно, но для конкретных задач. Например, если транспорт велосипед то очевидно, что скорости >100км/ч из области фантастики. В программе можно сделать фильтр по скоростям зачищающий строки в файле от момента включения прибора до точек с такими скоростями если таковые будут. Вот вам конкретный пример. Мой трек по Абхазии. Дорога с множеством туннелей. Момент выключения прибора (или потери сигнала) фиксируется на треке - новая секция. Скорость 292,3 км/ч явно фантастическая. Программа должна будет удалить 3 точки в данном случае. Теперь по поводу точности. Если будет передаваться кривое время и будут соответственно определены кривые координаты, но зато правильная погрешность их определения это также никак не поможет в определении истинных координат